ref(time): Deprecate the legacy date and clock providers (JAVA-571) - #6043

System.nanoTime() is CLOCK_MONOTONIC on Android too, and
SystemClock.uptimeNanos() is API 34 against minSdk 21, so there is no
platform-specific uptime implementation to install. The setter had no
production caller and its only test was a test of itself, while still
occupying binary-compatibility surface in sentry.api.

ElapsedRealtimeClock keeps its seam: RateLimiter lives in the core
module but needs SystemClock.elapsedRealtimeNanos() on Android, which
only sentry-android-core can supply.

UptimeClock and JavaUptimeClock remain; call sites that want the
guarantee named in their type resolve the singleton directly.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The elapsed-real-time field carried a comment repeating its own type,
and both the setter and JavaElapsedRealtimeClock restated what the
ElapsedRealtimeClock javadoc already says at length.

The setter javadoc now answers the question a reader actually has when
they find a setter on an internal option: which platform installs one,
and why the core module cannot construct it itself.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…A-571)

Installs AndroidElapsedRealtimeClock in AndroidOptionsInitializer, beside
the existing SentryAndroidDateProvider. Nothing reads the clock yet, so
this changes no behaviour.

Without it the options seam added in this PR is inert on Android: the
default resolves to System.nanoTime(), which is CLOCK_MONOTONIC and stops
in deep sleep, so a reviewer sees a setter with no caller and Android
silently gets the guarantee the type says it does not provide. That was
the flaw in the previous attempt at this abstraction, where the Android
clock was built into a local and never installed.

io.sentry.android.core.internal is in apiValidation.ignoredPackages, so
there is no .api diff.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

SentryOptionsClockTest asserted that a LazyEvaluator-backed getter
returns what its setter was given; AndroidOptionsInitializerTest already
covers the setter for real, on the one caller that uses it.
JavaClocksTest asserted singleton identity and that a nanosecond counter
does not run backwards.

Neither can fail without the language failing first. DeadlineTest and
StopwatchTest, which cover the arithmetic this package exists to
centralise, are untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

SentryAndroidOptions now returns AndroidElapsedRealtimeClock from an
override, so SentryOptions no longer needs a setter and the core default
collapses to the singleton it always returned.

Three things get better. The setter was a mutation point on an option
nobody should swap, and it is gone from sentry.api. Android is correct
from construction rather than from the moment AndroidOptionsInitializer
runs, closing the window where a reader saw System.nanoTime(). And
consumers that take a clock in their constructor, as RateLimiter will,
keep their own injection point for tests, so nothing lost a seam.

The cost is that this is the only getter SentryAndroidOptions overrides;
every other platform swap is installed in AndroidOptionsInitializer.
Those are user-replaceable options, though, and this one is internal.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

It took a public constructor to match `new SentryAndroidDateProvider()`
on the line beside it in AndroidOptionsInitializer. That line is gone
now that SentryAndroidOptions overrides the getter, so the odd one out
was the clock rather than the neighbour.

With getInstance() it matches the two JVM clocks, and the field it was
stored in disappears: both overrides are now the same single line
returning a singleton.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The Deadline.in to Deadline.after rename did not regenerate
sentry/api/sentry.api, so :sentry:apiCheck failed on CI.

Two interfaces existed so that a call site could name which suspend
behaviour it needed, but only ANR detection wanted the one that excludes
deep sleep, and neither ANR path can be fooled by a suspend: ANRWatchDog
reports only once ActivityManager confirms NOT_RESPONDING, and
AnrProfilingIntegration parks its thread while backgrounded and resets
its baseline on wake.

That leaves one guarantee worth naming. Ticker, UptimeClock and
JavaUptimeClock are gone, and ElapsedRealtimeClock becomes
MonotonicClock, backed by elapsedRealtimeNanos() on Android and
nanoTime() on the JVM.

The type promises less than "clock" suggests: a tick carries no unit and
no epoch, and only differences between two ticks from the same instance
mean anything. "Ticker" keeps it from reading like a source of wall-clock
time.

Deadline.after now rejects a negative amount, since a deadline that
starts out in the past is a sign error at the call site and passed()
already expresses that case deliberately.

Also drops the "state that has not been populated yet" framing from the
Deadline.passed javadoc, covers isAfter on two equal deadlines, and
rewrites the tick-zero test comment to name the last-updated-timestamp
pattern it is about, rather than leaving "sentinel of 0" to be read as a
deadline of 0.

`When network is active but not connected with permission, return
DISCONNECTED` mocked an active network reporting isConnected=false
alongside NetworkCapabilities describing a validated WiFi link. Those
describe opposite worlds.

It passes today only because the empty connection cache reads as fresh
for the first two minutes of every boot (JAVA-717), which forces the
legacy activeNetworkInfo path where the capability mocks are never
consulted. buildInfo reports API 24, so once that bug is fixed the
provider reads capabilities and the test would fail for a reason that
has nothing to do with what it is named after.

Fixing the mocks first keeps that failure from being buried in the
commit that fixes the cache.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

lastCacheUpdateTime used 0 for "never populated" while being compared
against SystemClock.uptimeMillis(), which starts at 0 at boot. For the
first two minutes of every boot the empty cache therefore read as fresh,
so getConnectionStatus() skipped updateCache() and fell through to the
legacy activeNetworkInfo path instead of reading NetworkCapabilities.
The window reopens after every unregisterNetworkCallback(), which reset
the field to 0.

Switching clocks does not fix this on its own: elapsedRealtimeNanos()
also starts at 0 at boot. Any 0-means-unset long compared against a
boot-relative clock has the same flaw; only epoch millis made it safe,
because there 0 is 1970.

The cache now holds a Deadline, so "never populated" is expired by
construction and has no numeric value to get wrong. The provider takes
an MonotonicClock in place of ICurrentDateProvider, which is what
a two-minute TTL wants: it must keep counting while the device sleeps.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…-574)

Retry-after limits were java.util.Date values derived from
System.currentTimeMillis(). A wall clock is the wrong instrument for a
backoff window: it steps when the device syncs time, so an NTP
correction could lift a 60 second rate limit early or extend it by
however far the clock jumped. The limits now live on the monotonic
clock, which counts forward at a steady rate and keeps counting while
the device sleeps, which is what a server-dictated wait means.

Storing Deadline rather than a timestamp also removes the duplicated
parameter on applyRetryAfterOnlyIfLonger, which took both an absolute
deadline and the delay needed to reach it, and lets three JdkObsolete
and JavaUtilDate suppressions go with the Dates.

RateLimiter also took the whole SentryOptions while reading exactly
three methods from it. It now depends on RateLimiterConfig, declared
next to its consumer, so what a rate limiter touches is three lines to
read rather than three hundred. SentryOptions implements it with no new
methods, so every existing caller compiles unchanged.

Both existing constructors stay, so the .api diff is additions only. The
ICurrentDateProvider one is deprecated and adapts the injected provider
rather than ignoring it, since a custom ITransportFactory may be passing
one.

One boundary moves by a nanosecond: a limit used to be active while
`now <= deadline` and is now active while `now < deadline`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

All four check-in paths kept a `long startTime = System.nanoTime()` and
subtracted it in a finally block: CheckInUtils and the SentryCheckInAdvice
in sentry-spring, sentry-spring-jakarta and sentry-spring-7.

The clock now comes from the options, so a check-in measures on whatever
the SDK measures on: System.nanoTime() on the JVM, unchanged to the bit,
and SystemClock.elapsedRealtimeNanos() on Android. A cron job that spans a
suspend therefore reports the duration a user would measure rather than the
time the CPU happened to be awake, which is what a check-in duration is
meant to mean.

An uninitialised SDK still reaches a clock: NoOpScopes.getOptions() hands
back empty options, whose clock is the JVM one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The ANR tests advance the ticker from the test thread while the watchdog
thread reads it, which without volatile is a data race that can leave the
watchdog looking at a stale tick forever.

The watchdog took its readings from an ICurrentDateProvider lambda over
SystemClock.uptimeMillis(). The type named no clock, so a call site could
not tell what it was measuring, and the arithmetic -- now minus the last
tick, compared against a threshold -- was spelled out inline.

MonotonicClock and Deadline replace both: the clock is a named type, and
the watchdog asks the question it actually cares about, which is whether
the main thread has missed its window.

The clock counts deep sleep, which uptimeMillis() did not, so a suspend
between posting the ticker and checking it now looks like a missed
window. It cannot fabricate an ANR: the watchdog reports only once
ActivityManager confirms the process is NOT_RESPONDING, and on resume the
main thread runs the ticker that is already queued.

Same reasoning as the watchdog: the suspicion and ANR thresholds are now
read from a named clock rather than SystemClock, and injecting it lets the
tests drive it directly instead of going through Robolectric's shadow
clock.

Deep sleep cannot inflate the measurement here either, because the polling
thread parks itself while the app is backgrounded and resets the baseline
when it wakes.

One interface carried two incompatible clocks: CurrentDateProvider is
System.currentTimeMillis() and AndroidCurrentDateProvider is
SystemClock.uptimeMillis(). Nothing in the name or the type said which,
which is the defect JAVA-571 is about — a field declared
ICurrentDateProvider accepts either, and the two disagree by however long
the device has been suspended. MonotonicClock names the guarantee it
gives, and SentryDateProvider covers wall time.

The annotation goes on the members rather than the types: the Android
modules compile at Java 8, where javac still warns on imports of a
deprecated type, and an import declaration cannot carry a
@SuppressWarnings. Deprecating getCurrentTimeMillis() and getInstance()
warns any caller just the same, and every warning it produces lands
somewhere that can be suppressed.

Each suppression names the replacement the site should take at the next
major. Several of these must stay on the wall clock: AnrV2Integration,
TombstoneIntegration and ApplicationExitInfoHistoryDispatcher compare
against epoch ApplicationExitInfo timestamps, and LifecycleWatcher against
Session.getStarted().

…VA-571)

Its own javadoc already told callers to prefer options.getDateProvider();
this makes the compiler say so. The static holder cannot be configured or
stubbed, which is the whole reason the note was there.

Annotated on the method rather than the class, for the same import reason
as the current-date providers.